Many companies are using multifactor authentication to provide a higher level of security to the services that they are providing. A common technique is to issue a token device that is used to generate a 4-6 digit code, based on the “Time Of Day” (TOD) and an internal algorithm with a secret key. This 4-6 digit code changes every few minutes and is input by the user, when prompted after he/she has input his/her name and password or some other form of authentication. Before the token device can be used, a device-specific secret key is registered with the server for each user, and may be kept on a server as part of the user's identity. Each new device requires that a new entry is added to the data store for the user. Each user has a unique entry for each device, which is stored on the authenticating server's data storage. Many times this is done as part of the user's identity store such as Lightweight Directory Access Protocol (LDAP) store, but can also be a separate data store. These token devices can be small hardware devices that can be stored on a user's key chain, such that the user can look at a small display and read the Time-based One Time Password (TOTP) each time he/she needs to enter his/her TOTP value. Smart mobile devices with custom applications are starting to replace the hardware-based tokens by generating the time-based tokens for the user.
The technique of providing a one-time password word works fine when the user has an identity that is stored in a directory that can be updated with the device-specific key. The problem comes when there is not a writeable-user object or no user object at all, for a user wishing to use a TOTP approach. This has not been a real issue in the past because there has been a user object that was used to validate the password or other credentials.
Social networks have changed the landscape, by providing a simple single-sign on technique of authenticating to a service without a user store at the service. The service uses the identity data from a social service such as Facebook®, and keeps nothing else. The problem is that the service may need or may want more validation than Facebook® can provide. To use TOTP, the service needs to store a secret for each token device that is registered, even if there is not an account for the end user at the service. This new data storage requirement adds a cost to the service, which can be from 10 cents to $1 per year for each user. With accessed systems of social networks there is the potential of tens of thousands, hundreds of millions, or even billions of users. This can add a large recurring cost to the service for the extra security. With the use of mobile devices as the token device, the cost of the token devices becomes low or zero, but there is a cost of keeping the device key at the service (and each user may have multiple devices). In large environments were servers must be clustered, the cost of keeping a shared and fault tolerant database can be very high.